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A METHOD FOR OPERATING PROAGTXVELY SECURED APPLICATIONS 

on 1 aii Insecure - system 

PIEID OF THE INVENTION 1 



> ■■ - — f 



The present invention's, in ..the general field of 
proactive security system and related applications. 



BACKGROUND OF THE INVENTION 

Traditional security systems assume that one or more 
systems are always secure, " i. e . are never controlled by 
the attackers. The mo^ei of' Proactive Security does not 
make this assimptioh/^ihste'adV it considers cases where 
all components of>- 'the- "'sy stem .may. be. broken-into and 
controlled by an "^at'ltacker,;. with" ' restrictions on the 
number of components- :bib ken- in ^to . during the same .time 
periods (day / week, . ...) ; - v " : > 

Proactive security '^shows how to maintain the overall 
security of a system . even under such conditions. In 
particular, it provides, automated recovery of the security 
of individual components, avoiding the use of expensive 
and inconvenient manual processes (except for some 
"aggressive" attacks/ which cannot be prevented - but are 
definitely and clearly detected) . The technique combines 
two well-known approaches; to 'enhance the security of the 
system: distributed '(or threshold) cryptograph, which 
ensures security as long as a threshold (say half) of the 
servers are not corrupted and periodic, refresh (or 
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update; of the sensitive" "dk a l^?-"_K e y s) held by the 
servers. In short, 



Proactive* distribute* > refresh ^ 

This way, ^he^>r : ^^ guarantees 
uninterrupted secuiifef ^g : I^ot c too many servers 
are broken at the^'iami^ t fme ? ; " ; Fur t J he r rmbr e , it does not 
require identif icatidn^'when^ a^ -system ^is broken into, or 
after the attacker* las^ : 'cbntroi; c instead, the system 
proactively invoked recovery procedures every so often, 
hoping to restore security to components over which the 
attacker lost Control /;-; :l * '\*~ ! ^. 

Proactive security^ is £ ' vo nighi^ desirable in many 
realistic settings> r ^n^a^ticu^ar;;;^ /' : 

• When a high level %f ^e^urity :: .±s Required, together 
with fault tofbr^nce - : tas " redundancy improves fault 
tolerance but opefis^iriore. -points for attack). 

• To ensure acceptable level of system using weakly 
secure components such as most commercially available 
operating systems. 

Recent results show that many fundamental cryptographic 
functionalities may be/, achieved even under the proactive 
security model - as long as most components are secure 
most of the time; ' in' particular, proactively secure 
protocols have been Revised for the following problems 
(see General Overview in : [2]':V 

• Secret sharing-. 
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. Discrete-log-based' ^-digital - signatures, and in 
particular DSA ; 

• Secure and- end-to -end y.commurii cat ion 

. RSA and in particulirjgeneiltiof J;of the RSA shared key 
Pseudo-random generation'-. ' " 

• Key distribution center .'. , 

. This substantial of known J results in proactive 

security did not ?^et:/ produce any practical security 
product or solution? M In fact, there are only a few 
developments of distributed security - the most well 
known may be" "the ' SET credit card standard^ 
certificate authority; see also -related art' below). 
The creation of ''such" a proactive solution is 
non-trivial, as the^rotocols aire often quite complex 
and nontrivial-:-' f fco s ' iAplement.. .. : Furthermore, the 
protocols are specified untie r "some simplifying 
assumptions and'/db^jpt ^ddressVsome needed elements, 
such as interfacing; between the 'proactive service and 
the applications using ' i t '. 

Applications of the Proactive Security Services 

There are- three kinds > of -applications that may take 
advantage of the proactive security* services, as follows: 
. centralized applications' - a "traditional" application 
running., on one ..server only.. ? , : The ,- application uses a 
proactively secure service provided by the toolkit. 
For some applications and services, this could provide 
a significant advantage, \ at minimal change to existing 
applications. Some -typical applications are: 
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• Secure loggi^^ach ~We«t ^application may add 

entries (events)" to" the log; however, none of them can 
modify or erase the*iog:%iS ; of great value 

in improving -irrtrusfSn^dfetfect^; ^oois 1 ) as intruders 
often try to erase^races? in log files. 

• Secure emd-to-enii " coaa^icktion: the proactive 
environment can^i^&^he applications with freshly 
generated and ceitf&d Jeys^eriodically . This 
could be integia^ed^witH^tunnei^ such as 
secure IP or SSL : . : - 



• Timestamplng t- can M us^cb to^ign'* document (or its 
hash) and current 'M^rd y ~ : t b : ^6veT 'that the document 
existed at this time; . >r '-. 



• -■■■:':icju".' t. ion ovl - 



Distributed : a^iicition^f • ^-ihe Application runs 
siiwaltaneously rv iAll ;i, Wrveti: (App_l..., App_n) and 
requests servic^^h^u|h^aii^ 3 efVers. Each App I 
interacts directly^ with its' own proactive server 
(PS-I) . A typical . application is a certificate 
authority, or "in general any workflow application 
requiring secure '(multi-person) digital signatures. 
Another application, is key., recovery , (escrow agents). 
Proactive applications -'the" application runs in a 
distributed configuration . but, in addition, goes 
through periodical,., refreshes by utilizing the 
proactive services/ This, is. required when the 
application security or efficiency requirements cannot 
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be met by the seirvicWs'. Examples include multiparty 
protocols such' ^s" voting and trading, database, 
operating system -' and access control mechanisms. 
Another application' is ' a ; Secure. : Commerce Server - such 
server cannot lie v behind the - firewall although it 
handles confidential;: data and matters (such as access 
control, certificates, etc:),.,:, --it- is therefore natural 
to proactively, .distribute the server among a number of 
(independent, a^d,#oss : ibly not^ : even mutually trusted) 
hosts and locations?.- thus . achieving increased trust in 
the server. 



Related Art: 
REFERENCES 



1. D. Boneh and M^j jJPtajvkljin^ ^Efficient generation of 
■shared RSA keys, ^iri > roc.. ; >ryp^o .V97, pp. 425-539. 

2. R. Canetti, R. Gehnaroy A. Herzberg and D. Naor, 

Proactive Security: tbng-term protection against 
break-ins. CryptoBytes : ' the technical newsletter of 
RSA Labs, Vol.- 3,, /number 1 - Spring, 1997. 

3. R. Canetti, S>. ' ! Halev± • and' ,A^-Herzteerg; "Maintaining 

authenticated co&uAication T in the presence of 
break-ins". • To ? ^be published: in Journal of 
Cryptography, c 19?ai- An; "extended abstract of this 
paper appeared -i Lri^the. ^Proceedings of the 16 th ACM 
Symp. On Principles; of Distributed Computation. 1997 
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4. C.S. Chow and ^A^V&iz^erg;- ATetwor*: randomisation 

protocol : A proactive : psiSdo-random genera tor . 
Appears in PrqE: USENIx' : MlX ^Security Symposium, 

Salt Lake Cit^^ahr June^l99§,, pp. 55-63. 

5. V. Hamilton, G. National Labs, 

Implementation^ ^ pr^ public-key 
protocols r Pr6ceeW^of% e ; 1998-RSA Data Security 
Conference."" ^Lff^^r'^ ' J- V"' 

6. A. Herzberg, M- \ J a. kob s so n / . SV^arecki, H. Krawczyk 
and M . Yun g r 'Proa cti ve ? publ ic k ey and signature 



systems, ACM. Security ' 91 . 



There are a "f ew impleme^tio^ efforts of proactive 
algorithms. Specif icSffy, b: '.the. : Network Randomization 
Protocol (NRP) of - :i [4n' whifc^pro^ides a proactive 
pseudo-random gen^^^^^^if^ ed at 1BM * In 
the latter it is rC Sslume^ _" that^- there is no global 
information common-' to%^ P 'roa^ive /servers and therefore, 
obviously, there is^o. need^to 'restore it after loss or 
corruption. This assmriptlon poses ^undue" constraint insofar 
as some commercial applications are concerned. 

Another effort, the implementation of proactive 
threshold key protocols,.; has' been reported in [5]. 

Whilst there , have been efforts to deal with 
applications where ,", global • information.,, is restored in 
response to loss or. corruption they, all require to store 
in a protected environment (e.g. ROM) information that is 
related to the group of proactive servers. Obviously, this 
information is not available when the server is 
manufactured and sold, but only much later - when it is 



000000 



integrated into .a .^ecific .proactive environment. 
Accordingly, incorporation of such information requires a 
relatively sophisticated 1 hardware and is of static nature, 
meaning that after having : incorporated the group related 
global information •3fn' C -°tHe; ROM • (or -equivalent hardware), 
the information caxmot^e "a^ltered,- if, say, the group 
members change. < ; .v . -., --- . 

Overview o£ the Proactive Model and Algorithms 

' .. -j3-'--i " ! ; '■" " ■': . s • :' 

Model . 

The proactive model described" below' assumes typically 
(although not necessarily? the following. A^set of n 
servers {P1,P2M that^ape interconnected by complete 
point-to-point communication channels. Time is divided 
into periods (like' daysf weeksix which are determined by 
some global clock. An. adversary : ma y ;- (temporarily) attach 
up to t of the n servers "it a'nyigtven time period - but at 
different time P eriodsV y dif f^rent?sets of t servers can be 
attacked. As a result ^servers: engage in a refreshment 
stage at the beginning o'f "each : time period, so that any 
server which has been attacked during past periods may 
automatically recover from possible undetected break-ins. 
corruption is assumed to> either static (for example, 
disconnect a server fronTthe rest of the network, 
eavesdrop, read secr^^ata) or ;a6fcive /malicious (for 
example, deviate from thV protocol, \ corrupt local data, 
etc ). Therefore, after the attacker loses control over a 
server, the attacker may^ still know secret information of 
that server (e.g. passwords or secret keys). Furthermore, 
before losing control /the attacker may have corrupted 
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(modified) some of theOTr^^.(M ; public keys of 
certificate authoriti^^Ae^ref rjstaent - stage deals with 

both aspects, . ; i . e ~ **** and 

invalidates any old'" sec|e| : dl_t4l'(^y^°J|f n « new secrets 
or splitting global: S ;ecr^ts-J:'iiit^ 'f&-° £ shares) • 

This brings the SBrviztbaf\i : to\.k-^m^9jat^g9. and 
guarantees that any .^fqfim^ion Vthat ~was ^gathered by the 
adversary becomes worthies s.' after "reqov$ry . 



The fact that the: ^ta^er ^Is Viimited^ to t corruptions, 
out of a servers, ■tf^§larJ'o the distributed (or 
threshold) security'" model uSed* man? works in distributed 
computing and cryptography''. However, ' in ^ the proactive 
security model, ^'i^^'to^o^to corrupt every 
server - as long? 'as does?. nof\ corrupt more than t 
servers at the sain^ period ^Th|* aSv^sary ' in the proactive 
model is ''mobiU^V.na^fyfa^ac^'e^-' "components may be 
released at some poln£?(due/; to some security measure or 
other change in th«T system >r & the^ adversary causing loss 
of control, often as -^a result"- of; _ an attempt by the 
adversary to avoid j defection'' or ihe" attack) . Furthermore, 
in contrast to other:. : approaches, proactively secure 
systems do not necessarily? wait, until a break-in is 
detected. Accordingly, • a proactively secure system may 
invoke the refreshment protocol periodically (and 
• proactively) in orde'r "?to ^ mainta£fi^ u £in£'errupted security, 
or force detection. For more discussion on the motivation 
behind this model, see. [2,3] - 

Some attacks on th*. system cannot be prevented. The 
■classical' example is ' if "the attacker is breaking into a 
server, thereby finding, all its secret keys; it then 
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pretends to be that 5 ; ; ^er: while keeping this server 
disconnected from the J other servers (when the attacker 
lost control over, that.^ server) / . However, in such cases, 
the attack can- be detected iank raise .an. .alert - inform the 
operator about the attain, i Operators: will normally respond 
to such an alert by irivokirig special- emergency security 
resources and procedure?, : which" aire^very likely to remove 
the attacker - and^ssibly .pa^ch.; her as well. Therefore, 
it is highly unlikely' th|t ; Vsmart) attacker will use such 
•visible' attacks. 

The proactive security Wdel assumes that even during 
' attack, some specif ic^ata cannot be corrupted. The 
obvious example for data that ^ is assumed not to be 
corrupted is the "program' itself r if it could be changed, 
recovery is clearly". i^ossiblW. -Vlearry, the program is 
not any different than- ''any " constant value " used by the 
program; It is assumed that each computer proactive server 
comes with a read, only "memory-' which can specify its 
contents. Specif ically^^t: 'is -assuiiied that each computer 
(proactive server) comes '.with such a non-erasable storage, 
e.g., a read only memory (ROM) containing a fixed public 
key, and the corresponding secret key is known only at 
initialization as will" be explained in greater detail 
below. This assumption Is not too difficult to implement 
in practice. The characteristics.- -of the specified model 
are described for clarity of explanation and accordingly 
those versed in the ' art wil1 " « adil V appreciate that 
various alterations and modifications may be applied, all 
as required and appropriate " depending upon the particular 
application. 
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There is accordingly" a' need in" the" art to provide for 
an operating environment of a' network of servers which are 
set up once (designated group of protective servers) . Each 
server is instantiated preferably at boot time by the 
operating system and is checked periodically, also by the 
operating system. Servers can recover data (both public 
and private data) from- self or other servers in the 
proactive network, if such data is corrupted or lost. 
There is a specific need in the art to provide for an 
initialization and recovery procedures for a proactive 
operating environment of the kind specified. 
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SUMMARY OF THE IKVENTIOT?: 



The invention,- provides" for a proactive 
operating environment that • includes; a group, of proactive 
servers communicating over a' network; each proactive 
server (PSx) comprising:. . 

a storage that includes a' non erasable part that 
stores at least a v pyfetic ; ,vr .non.J proactive related, key 
V*, M « ; said storage" .further includes an erasable part 
for storing private ^nd' public data; said proactive 
server is further assocflt'^dV witlPa discardable one-time 
private key S x sta rt triat corresponds to said public key 
V 1 sta rt/ said proactive "server is., further associated with 
configuration data C; . v 

a processor' for^ providing" .'at"'' least proactive 

services to applications;" 

the proactive 'server is associated with a group 

public proactive key Vcwr common to said group of 
proactive servers d^^'Mri'-f^'of a corresponding 

private proactive key Sceit; ' - ; • 

the processor ; is -operatWe to -invoke initialization 
procedure for generating restore related inf ormation; 

the processor- is' further; operative to invoke a 
restore procedure for utilizing at. least said public, non 
proactive related,' '• key' .V^Va^bald restore related 
information for restoring at least said public proactive 
key Vcert' 

The invention further provides for a method for 
providing a proactive, security iry proactive operating 

oooooo ^ 



environment; the proactive operating- environment includes 
a group of proactive servers communicating over a 
network; each proactive 'server (PSj) comprising: 

a storage that 'includes a non erasable part that 
stores at least / a~ public , npn> proactive related, key 
ytsttrz S said, storage" further includes " an erasable part 
for storing private ; an s d ' public'"''' data; said proactive 
server is further associated"' with 'a discardable one-time 

private key s'szart'^^^^^^^^^ said P ublic key 
V^tazt; said proactive' 'server is further associated with 

configuration data C; .. = -,\ . .. _ ; 

a processor-/ f or"%rovi'ding' at ^ least proactive 

services to applications; 

the proactive server is associated with a group 
public proactive key ~ : V C£RT ^ common to said group of 
proactive server/'and; a, share &r of a corresponding 
private proactive' key S CSRt ; the method further including: 

invoking initialization .procedure for generating 
restore related information; and invoking a restore 
procedure for utilizing at least said public, non 
proactive related, , key^V^rt and said restore related 
information for restoring J a^,ieast said public proactive 
key Vcs&t- 
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Still further, the~ : ;invent ion provides for a storage 
medium storing computer? ^ impiemented/ program for providing 
a proactive security ,in proactive; operating environment; 
the proactive operating -environment includes a group of 
proactive servers communicating over a network; each 
proactive server ~(PSi) comprising: 

a storage that includes a non erasable part that 
stores at least a , public, npn ^ proactive related, key 
V^tart / said storage further includes an erasable, part 
for storing private and public 1 data; said proactive 
server is further associated with a discardable one-time 
private key S z st*rt_ thVt 'f corresponds to said public key 
V^start/ said proactive'.' server is "further associated with 
configuration data C; \[ 

a processor for "'providing at least proactive 
services to applications; 

the proactive server . is associated with a group 

public proactive key, Vcert common to said group of 

proactive servers and^a;- share S x c£*r of a corresponding 
private proactive key Scert; the method further including: 

invoking initialization procedure for generating 
restore related information; ' and invoking a restore 
procedure for utilizing; at ' least said public, non 
proactive related, key;:^ and said restore related 
information for restoring at least said public proactive 
key Vcfiftr- - ' ' " ' ' " ' 
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BRIEF DESCRIPTION OF THE DRAWINGS 

In order to -under stand. J the invention and to see how 
it may be carried out in- practice, a preferred embodiment 
will now be described, by way of non-limiting example 
5 only/ with reference v-.*to -the * accompanying drawings, in 

which: ■;;■;•); •:' ;> 

Fig. 1 is a 'generalized^,, proactive network in 
accordance with one embodiment- of .the- invention; 

Fig. 2 is . a : ^ "generaliz^of. 1 ' proactive server (PS) 
10 architecture in accordance with one embodiment of the 

invention; 

Fig- 3 is a flow** chart -illustrating an initialization 
procedure executed by a PS, in accordance with one 
embodiment of the invention; and 
15 Fig. 4 is .a., flow chart illustrating a recovery 



procedure executed by .a' 'PS/' "in " accordance with one 
embodiment of the invention.; 

DETAILED DESCRIPTION " OF SPECIFIC EMBODIMENTS 

There follows a: description of the basic architecture 
and functional operation - /,of , a -. proactive operation 
environment in accordance /with . one embodiment of the 
invention. 



Thus, the proactive operating "environment includes a 
network of servers (100) which is set up once - this 
network is referred to as the Proactive Network, or group 
of proactive servers • /{ see Figure 1) . Obviously, the 
30 network may include other servers which may form part of 
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other proactive group or groups, all as required and 
appropriate. It should; -^be noted that a server may be a 

member of two or. more' groups! -Server should not be 

-tiTit! ':■?.::■"; : 
construed as boungl . ..:,to ...... any ; . specif ic platform or 

architecture . ,7 ■ ... " 

Each node in the- ..-network \.runs a proactive server 
{Pserver), of which only 5 are shown (101 to 105). The 
basic, non limiting, architecture of Pserver (200) (in 
accordance with one. embodiment) is depicted in Figure 2. 
Thus, a Pserver communicates with other Pservers via the 
proactive network (205) and provides proactive services 
to applications (designated ^generally as (201) ) by means 
of, say, Application Programming Interface (API). A server 
is initiated at boot ''time' (203) 'and checked periodically 
by the operating system' "(2 04) V. ' \ 

Modules of the Pserver-^' : ; 

By a non-limiting r emt^Uim¥rit/ vthe 5 internal design of 
Pserver (200) is composed of ;;the following modules: 

• The Controller: This is the main "engine" of the 
program. It manages.. ; the .Pserver data, dispatches 
incoming messages to : appropriate protocols in the 
protocols tree,/ keeps the' status of the proactive 
network (namely, wriich nodes are active and running) . 

• Communi cation Module:/ This module is responsible for 
the secure transmission and "receipt of messages 



across the proactive network '/ind .with the various 
applications that thS PseYv'er services. 

Library of Proactive , : U^.lit^es:. ..This . library is built 
upon a standard" ifcryptj^a^lc: library and is a 
collection of uti;i£ies^ that are needed for 

implementation of proactive algorithms and protocols. 
It includes, f or c texam&ieV : "Shamir"* s secret sharing 
SSO, Feldman's Verifiable "'Secret Sharing, Joint 
Secret Sharing 'and '"error- correcting polynomial 
interpolation. Note 1 ' : "' tKat %his'" : library concerns 
preferably f urictlonalitiSs 'tWfe" are needed locally in 
order to perfb'rnf trie 7 ' 'pro'tocois . 

Library of Proactive , ^r6^TO^^? , ':: A-;.proactive protocol 
(in contrast to : a° proact^ is a thread of 

code that is executed at oner 's erver ' and performs the 
logical flow of communication steps required by a 
certain protocol, ~ using the proactive utilities 
library for its local computations. The 
implementation is 'phased r e . g. • on a collection of 
protocols that ;,are; : ; executed by- the Pservers (either 
for its proper operation or as a proactive service to 
other applications) J . Examples \ of protocols are all 
variants of Secret Sharing protocols, as well as the 
Initialization and. Recover "Procedures, according to 
the invention which will be described in greater 
detail below: 
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The API Module^ A module that ^provides interface to 
applications that r >r,un pver -the proactive operating 
environment. 



The Pserver Data 



The Pserver,,. maintains some, key internal data. 
However, the maintenance of these data ^raises a few 
algorithmic problems/; -as ! the! server must be able to 
refresh and recover " '. itself periodically, and this 
includes recovering it 's^kAt a "or -at" 'least verifying that 
it has not been corrupted. r= The server's data is one of 
three types- The specified '"data" are stored in various 
modules designated generally as storage (206) in Fig. 2, 
as follows: . " v. . - . 

1. ROM (or other non-erasable part) data - these "write 
once" data is assumed to be * immutable so that any 
attack on the system" cannot tamper' with it, however, 
an adversary may learri it- It is used for 
bootstrapping purposes . as otherwise a recovering 
server could not bring itself to a secured state. 
The design, as detailed . below, attempts to minimize 
the amount of data that must be stored in the ROM in 
order to safely rbpot the ' server; in particular it 
shows that is? .suffices ;: to store a public (non 
proactive related)'. key, - e.g. server's unique 
identification code /or the - server's port number in 
the ROM for the! Pserver to be completely 
recoverable. The invention- is, however, not bound by 
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any specific data^l^at^are^ stored, in the ROM and 
likewise not W ^tHe/ pul^ic and private data 
described below/ 



Public data: Part&^of "thi:sy -df tav ajce' common to all 
servers, but^.bther' p^ts ' are' specified to the 
particular Fs^e^^^i^tsCe^osuxe to the entire 
proactive network r " does' "not interfere with the 
security of a "Ps er vet. ' since " these data are 
necessary for the proper operation of any server and 
thus must be recbVera'ble\ / "The '^public data are 
preferably duplicated "among all" servers so that 
during recovery the' 'data' can be '"* reconstructed if 
need with the" as si si an ce off the proactive network. 
The details of , thts proems; are^scribed below. The 
public data may' the lifetime of 

the system, fof ex^mple"^ generating new long-lived 
secrets (the'^om^ "fields ' of ' "these long-lived 
secrets is added tp : -the public information) . 

Private data, specific to a particular server. One 
such example is tfie : server's share of a private 
proactive key. These, data are typically not 
recovered, but' ^instead are refreshed. It also 
requires (e.g.. for;; the one-time private key) the 
ability to 'bei-i- c^l€X^.^Za£e&» from the system 
without leaving any. 'traces, which is a property that 
needs to be supported by the operating system. 
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The Proactive Seeuxx^..-.opoeratien •■ •.. : 

In accordance 'with'' the ; invention, a proactive 
operating environment "fiuWt ^i#aih proactively secure 
communication amohgJth^lse^yers^as well as a proactive 
internal signature Jcey...;for ; the '^entire lifetime of the 
system. For that, these" \wj "protocols must be initiated 
and undergo refresh' a^^e'r/ period> where a refresh may 
actually involve recovering ' in ' any ^ server if that server 
had detected that some^f its "da&^as' 7 corrupted or lost. 
Publication [3] provides ' tine design of the integrated 
proactive protocols" **o£ '"' ' signatures and secure 
communication, and:, '[^V -foi /the specific proactive 
signature mechanisnu However> [3]^xequires every server 
to keep in read-only memory :' (ROM)- 'a copy of the public 
non-proactive relaWfnW^ • (whose corresponding 

secret key Scert ) ^^s^a'red between all the proactive 
servers, and these shade's & ceri(tf are refreshed at every 
period t. This assumption, is not' very practical, as the 
public key Vcert (common : ..to ; the' group of proactive 
servers) is not . available, when the computer is 
manufactured and sold,-but only much later - when it is 
integrated into a .specific proactive environment. In 
accordance with the 'V preferred' • embodiment of the 
invention, it is shown' how to' provide the requirements of 
[3] while requiring only that! each computer comes with 
pre-installed, machihetunique pair of secret key S^taxt 
(e.g. on erasable disk) J serving as the one-time private 
key and public key (on ROM) . It is accordingly 
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appreciated that unli^^ticj^t^ T^sifart "is unique and not 
group related. - 5. pf : .o: ; . =nv.. v.- 
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Another practical ^aspect ^whichi'V has, to be dealt with 

is that the proactive ,. : server' \- needs some constants 

configuration information such as: .=IP :; addresses of other 

servers, cryptographic' parameters . . ^ used in the 

cyrptographic algorithms, " and, so on.' The set of these 

(public) constants^ are * : ' denoted ' by C. The proposed 

^ " : ;; r> t i X v , • ^ • • 

protocols include mechanisms to" recover C periodically 

« - ■■' : z -i -,i : ; t ; - . • 
(if the adversary corrupted C when breaking onto the 

server at the previous period) . Let Mi = [S 1 ^^ (V cerz/ C) J be 

the signature of server J on • ( V e&r t r C) using its initial 

key S r start . M denotes the concatenation of all ATI's, that 

15 is M=(M lr M 2 „MJ . Hencei"'. is v €fie .rlvvar&nt Information of 

, '*'.'* The? fcal " ir" \x)' r : - 

the system. 

Publication [3] prbvicles 'a review J "of the periodical 
refresn protocol, which assumes the availability of an 
unmodified Vcert at every proactive server. Typically, 
although not necessarily, the recover procedure of the 
invention is invoked v "when the ■ refresh ^procedure has 
encountered loss or corruption of* data that needs to be 
recovered, ' 

The initialization "protocol is executed, preferably, 
25 at the setup of -the system ^ and is described with 

reference to Fig / '3 ; L The goaf c ls^ 'to "bring the servers to 
a state from which they can^.safely perform the recover 
module at the refresh, stage, if necessary, and accomplish 
proper operation of . the system. To this end, the 
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initialize procedure generate a so called restore related 
information. 

The input to the protocol (i.e. the initialize 
procedure (301) is * the ' configuration (designated 
generally as C and (S J st art/ V^itart ) >' where V^start is the 
public non proactive related part of the key stored in 
the ROM module of the proactive data (206) . V^szarz is 
considered non-proactive ^ as it is not group related. Put 
differently, the same V^rt key may be used for the 
Pserver #i regardless of the group of proactive servers 
to which it belongs. V^staxz stands/ for example, for the 
PS unique identification code embedded in the ROM during 
manufacture. S T s tart is the corresponding private key which 
is used once and must be -discarded afterwards. 
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At first (302-305) ^^ a* fet "of keys S z (0), Vj (0) , 
Ej(0), D x (0) are generated, and all except Di(0) are 
broadcast over the .."network ", channel to the rest of the 
servers (I , . i-1 so as," to authenticate and 

enc r yp t the ch ann el, . ~ a 1 1 . - a s : .kn own per se. As is well 
known the E I (0) / Dx(d)^ are 'bptipnai whereas S x (0) , V x (0) 
are, as a rule (albel.t.^ 

Next/ a pair r ";;' of; c ' r .keys are" ^generated, i.e. group 
public proactive key is generated V Cer t and a share of the 
corresponding private^ "key ' S Ce rt (306) by a well known 
procedure (e.g. see [1] )"*' (307) ' giving rise to V C6 rt public 
key common to the group of the proactive servers. S 1 c e rr is 
the pr i vat e secret' s T har e : --o f SP ' ( i ) . ' ■ 

Any message sighed^by, V c ^ rt . is assumed to be truly 
signed by the members of the" group. 

In the next steps" a V j 6 in t ' "s ign at ufe ( S c <srt (M) ,M) is 
generated/ standing," preferably, for the ' invariant 
information to help recovering servers (as will be 
explained in greater detail >below) 

To this end, the Vcik public, key and the 
configuration C are signed using the one-time private key 
S start so as to constitute' Mj "message (308) . In this 
connection, it should be hot eel that the configuration C 
is not bound to any specific contents and may vary, 
depending upon the particular application. Having 
generated M Ir the one-time private key S J S t&rt is discarded 
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(309) , such that it,, can;- no longer be accessed and used by 
any other node. ^ ' ' ' ' . ..V. . 

Mi is now broadcasted" to. a 11^; 1 ahd?Mj is received from 
all respective SPj. (310);. t: : KoU- t ..th£": Invariant Info is 
constructed by cdnc.atena'tirig *"Mi;''.MiT (Sill) and is signed 
(312) so as to generate/tke "Joint, signature (5 Cer t (M) ,M) . 

The information ■ generated : " by the initialize 
procedure, and which "wi'l'i later " be used by the restore 
procedure, constitutes one form of restore related 
information (e.g., V5 c ^^'(M)vM) ; S J swrt ' (V Cfirt CJ . 

It should be noted . that the restore related 
information includes a ."'self/' ] psirt .serving for restoring 
at least the V cert . /arid '-.pos sib ly "other) info (e.g. the 
specified M x ) of thV-Jspecif ied Pserver, and optionally 
also "others" part ^Xe. t g. /. the Scare (M) ,M) ) which will 
assist other servers" V/in" the group to recover their 
respective V cert (and possibly other) info. It should be 
noted that in the specific example described herein, each 
server generated,. " other i'' .info (i.e. M and signed M) 
which enable any other server in .the group to restore its 
Vcert info solely relying on the ; pothers" info of that 
particular server/ since;.' M is;, a" concatenation of the M x 
parts of each one of the other.' members in the group. 
Thus, any server which is subject, to corrupted or loss of 
Vcert info, will be able ' on the basis of the verified M 
received from the specified ""other" : server to extract its 



oooooo 



23 



respective M t and using '"the '^fitkzt "key stored in its ROM, 
to construct V CQ ^t (B.^^poksj^\y o^n^x lost data).. 

Those versed in /the"! 'art : '.wilf. readily appreciate that 
this is not necessarily[ u .always :■ theu= case. Thus, for 
5 example, by another. 1 e^.odiment a given Pserver can 

recover the V cer t info" on ' the basis of "others" info 
received from two or more of * the' "specified group members. 
In this connection' ' it 1 '- : should be : hoted, generally, that 
the unlike the "self " r ihf o ' that 5 is "always generated, the 
10 "others" info is generated only when required, depending 

upon the particular appli"cat-i'ohV' L " 

Having compieted'^f^e "initialization procedure, the 
SP is ready for..." /trie ; /recovery r ,;.;p^ocedu : re which may be 
invoked by the refresh - prdfcSdure; v: as described above. The 
15 recover procedure^ u'tiif^s^rthe" restore related data 

generated by the initialization procedure. 

At the beginning?: o£ every' recover, Vcert is 
regenerated and the constant C is restored for any server 

v. 

which lost these ydata. As : a result, it brings a 
20 recovering server ; to ; r ; a 2 st ^te . from which it can 

participate in the Refresh protocol described above. It 
is assumed that any operational server has a valid copy 
of a signature on M,o the Invariant Information of the 
system, sighed by' the .-distributed signature key Scert - 
25 an assumption that* isf supported \hy the initialization 

module described abovey-:; 
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Essentially,. . ;this^protqcol;f allows any recovering 
server to gather Af; ~ the . Invariant Information of the 
system, from other, operational . servers as long as there 
are enough of them* Note ithat \.M\ needs to be 'pushed* 
around the system since : a, recovering; server may not known 
who its partners ; are.;, (recall;: ..that v C, the program 
constants, contains information -such : as IP addresses) - 
The protocol is executed ,r by: -a;il: : servers, and by the end 

of it, a server detects.^; whether-- it is. ■- ' operational 1 or 

xf~ :'X;Ay TO -'-7 -■■ ~ '- -* : 
1 recovering 1 . * c;: r ^i:: * ; >v '/.x; - 



Turning to Fig: 4, : -.-'at "first, V 1 start is extracted 
from the ROM (401)". In- order to validate the joint 
signature (Scerz (M) ,M)/.' (402) the" following procedure is 
invoked. To this end, '^fehW" V^xt "should" first be extracted 
which necessitates- t6' : ^xtr^cf' iir from jtf'(403) . This can be 
easily accomplished considering that. Af. is a concatenation 
of Mi.. M N . Having r :/pbtained" % constructed by 

applying V* S tarc (that' is^'available r to" the recovering SP as 
it is stored in the ' ROM/" 1 to " M z . "'It is recalled in this 

'C-7 ■ ■ '''•~t~. '• ' £"'-■' * ; * '"^'T ' 

connection that " " consists of • • ' S^tart (Vcextr c; , and 
accordingly applying .^t^ thereto will give rise to Vcert 
(and the Configuration C) . 



Those versed in the' -art >will ; readily appreciate that 
by using a unique ' keyv. a'-pridri^'tpr ed(±n the ROM, the 
recovering SP is able i.t;o^ restore. : the Vcert key* which is 
group dependent (non-proactive related) . It is recalled 
in this connection, /that according to hitherto known 
techniques, it was required to maintain the group 
dependent key for ..the ; : v recovery procedure. This 
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requirement according. ." to ;.. the ./-prior- are posed undue 
constraint as it was required to- ernlped during manufacture 
(or afterwards using" "dedicated .expensive hardware) a 
group dependent key. in ^each 'SP, whereas according to the 
present invention, it xs'suf £icie4it to embed a unique key 
V STA rt (say the SP . identification., code)" and . therefrom to 
reconstruct the group .dependent 1 key .Vcestr..- 

Having constructed 'V CE rt, (405) the latter is used to 
validate M by applying V C ert to the joint signature 
part(S C(5 rt (M) ) (406) /"'if the " result matches M (which is 
explicitly included in the : j oint signature) (407), then 
the server becomes operational (408) . In other words, by 
validating M, the recovering " server has confirmed the 
validity of all Mj of tfe respective S?s and consequently 
has confirmed that each corresponding SPj is a member in 
the group. M and ' ScJi "'"'{&)' ' are '■'then 'Sent to all the members 
(409) allowing each "one of them to exploit AT for 
recovering its self "V C ert^ 

If, on the other,; ihand, : M .is invalid (i.e. the 
application of Vqsrt, in : ,..step )r (406) did not result in M, 
then the SP await the receipt of another joint signature 
(410 and 411) and in.r -response repeats steps (403) and 
onwards until M is validated. 

• :90 c; 7 

In the claims below, alphabetical letters and roman 
symbols are used for convenience only and do not 
necessarily imply any order of the method steps. 
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The present invention • has been described with a 
certain degree of particularity, but various alterations 
and modifications may be carried out without departing 
from the scope of the following claims: 
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